Software systems, such as operating systems, utility programs, and application programs can be very complex systems that have many interdependent components (e.g., modules, drivers, and libraries) that access various resources (e.g., configuration files). From time to time, these software systems may need to be updated by updating or upgrading the existing software systems or installing new software systems. For example, a software system may need to be patched to fix a bug or upgraded to add enhanced capabilities. Because of the complexities of the software systems, it can be very difficult to assess the full impact of an update. For example, a dynamic link library may be shared by many components of a software system and by many different software systems. The library may be updated to include a new feature that is needed by one software system. Such an update may, however, cause the other software systems to malfunction.
In many situations, it is important to update software systems as soon as the need for the update arises. For example, although the Internet has had great successes in facilitating communications between computer systems and enabling electronic commerce, the computer systems connected to the Internet have been under almost constant attack by hackers seeking to disrupt their operation. Many of the attacks seek to exploit vulnerabilities of software systems including application programs or other computer programs executing on those computer systems. Developers of software systems and administrators of computer systems of an enterprise go to great effort and expense to identify and remove vulnerabilities. Because of the complexity of software systems, however, it is virtually impossible to identify and remove all vulnerabilities before software systems are released. After a software system is released, developers can become aware of vulnerabilities in various ways. A party with no malicious intent may identify a vulnerability and may secretly notify the developer so the vulnerability can be removed before a hacker identifies and exploits it. If a hacker identifies a vulnerability first, the developer may not learn of the vulnerability until it is exploited—sometimes with disastrous consequences. In either case, it is important to remove the vulnerability as soon as possible by updating the software system.
Regardless of how a developer finds out about a need for an update, the developer typically develops and distributes to system administrators “patches” or updates to the software system that addresses the need. If the need is not urgent (e.g., the vulnerability is not yet known to hackers), then a developer can design, implement, test, and distribute a patch in a disciplined way. If the need is urgent, then the developer may rush to distribute a patch without the same care that is used under normal circumstances. When patches are distributed to the administrators of the computer systems, they are responsible for scheduling and installing the patches.
Unfortunately, system administrators often delay the installation of patches for various reasons. When a patch is installed, the software system, and possibly the computer system on which it is executing, may need to be shut down and restarted or brought offline. If the software system is critical to the success of an organization, then the system administrator needs to analyze the tradeoffs of keeping the software system up and running with its associated risk of not installing the patch (e.g., being attacked by a hacker) and of shutting down a critical resource of the enterprise to install the patch. Some system administrators may delay the installation of the patch because they fear that, because of a hasty distribution, it might not be properly tested and could have unintended side effects such as with the software system itself that. was patched or causing a negative impact on other software systems or overall system performance and reliability. If the patch has an unintended side effect, then the software system, the computer system, or some other software component that is impacted by the patch may malfunction. In such a case, it may be very difficult and costly for a system administrator to undo the patch. Thus, these system administrators may delay installing a patch until experience by others indicates that there are no serious unintended side effects.
If a patch is to be installed, a system administrator would like to know all the software resources (e.g., applications, dynamic link libraries, and configuration information) that are affected by the patch and how they are affected. This knowledge would help the system administrator assess the full impact of the patch. Similarly, the developer of the patch would like to know all the software resources that are accessed by the software components of an enterprise. This knowledge would help the developer test the patch before it is distributed. Both system administrators and developers, however, would like to keep such information confidential. Developers are concerned that if information describing software affected by a patch (e.g., the source code) were to fall into the hands of a hacker, the hacker may be able to use the information to identify vulnerabilities and exploit them in systems that have not yet been patched. Developers may also be concerned that divulging these details may provide other parties a competitive advantage. Similarly, system administrators want to keep knowledge of their internal software systems confidential from competitors and potential hackers. To help with the analysis, system administrators could instrument their code (e.g., binaries or source code) to test a patch. Although the instrumenting of code can provide a very detailed analysis of interdependencies of software components, the instrumenting and analyzing of the results can be tedious and costly. In addition, the instrumenting of code can result in unintended side effects that may present new problems or obscure problems resulting from the patch.
It would be desirable to have a technique that would allow a system administrator to efficiently and effectively evaluate the effects of a patch while minimizing the disclosure of confidential information and without relying on instrumenting code.